Hierarchical database structures are increasingly important, because they help organize information in computer systems. In particular, hierarchical databases are used in large and complex computer networks by directory service providers. Directory services are sometimes called "naming services." Directory service hierarchical databases are also known as "directory service databases" or "directory service repositories".
A variety of directory service providers are now available to help administer both the location of network resources and the rights of network users to use those resources. Many, but not all, directory service tools conform at least in part with the X.500 directory services standard. One well-known directory service system includes NetWare Directory Services software commercially available from Novell, Inc. of Orem, Utah (NETWARE DIRECTORY SERVICES is a trademark of Novell, Inc.). As used herein, "Novell Directory Services" ("NDS") includes NetWare Directory Services and any other directory service commercially available from Novell, Inc.
A hierarchical database differs in several important ways from a relational database. Directory service repositories and other hierarchical databases are organized hierarchically, as one or more trees. Each object in a tree (except the root object) has exactly one parent. Objects may generally have children, which may inherit properties from their ancestor objects. Objects are instances of "classes," as described in detail below.
By contrast, each relational database is organized as a set of tables in which rows represent records and columns represent record fields. Certain fields may be found in multiple tables, and the values of these "key" or "index" fields are used to guide database searches. Database access and manipulation involve combining information from various tables into new combinations to obtain different views of the data.
The structure of at least one NDS directory services provider is defined by a schema. The schema includes a set of "attribute syntax" definitions, a set of "attribute" definitions, and a set of "object class" definitions. The NDS software and a default NDS schema are described in Bierer et al., NetWare 4 for Professionals, ISBN 1-56205-217-9("NetWare 4"), pages 255-342. The terms "attribute" and "property" are used interchangeably in NetWare 4 and herein, as are the terms "attribute syntax" and "property syntax."
Each attribute syntax in the schema is specified by an attribute syntax name and the kind and/or range of values that can be assigned to attributes of the given attribute syntax type. Attribute syntaxes include, without limitation, Case Exact String (case-sensitive string), Case Ignore List (case-insensitive string list), E-Mail Address, Net Address (valid addresses include IPX and AppleTalk), Path, and Stream. Attribute syntaxes correspond roughly to data types such as integer, float, string, file, stream, or Boolean, or to collections of these types, in conventional programming languages.
Each attribute in the schema has certain information associated with it. Each attribute has an attribute name and an attribute syntax type. The attribute name identifies the attribute, while the attribute syntax limits the values that are assumed by the attribute. For instance, the default NDS schema includes an attribute of syntax type integer having the name "supported connections" which specifies the number of concurrent connections a file server allows.
Each attribute may also have associated with it any or all of the following flags: Non-removable, Hidden, Public Read, Read Only, Single-Valued, Sized, and String. The general meanings of these flags are familiar to those of skill in the art. If the Sized flag is set for a given attribute, then upper and lower bounds (possibly including No Limit) are imposed on values to be held by that attribute.
Each object class in the schema also has certain information associated with it. Each object class has a class name which identifies it, a set of super classes that identifies the other classes from which this class inherits attributes, and a set of containment classes that identifies the classes permitted to contain instances of this class.
Each object class also has a container flag and an effective flag. The container flag indicates whether the class is a container class, that is, whether it is capable of containing instances of other object classes. The effective flag indicates whether instances of the class (objects) can be defined. Non-effective object classes are used only to define attributes that will be inherited by other classes, whereas effective classes are used to define inheritable attributes, to define instances, or to define both.
In addition, each object class groups together certain attributes. The naming attributes of an object class are those attributes that can be used to name objects belonging to the class. The mandatory attributes of an object class are those attributes that must exist in each valid instance of the class and/or become mandatory attributes of classes which inherit from the class. The optional attributes of an object class are those attributes that may, but need not, exist in each valid instance of the class. Optional attributes of a parent class become optional attributes of a child class which inherits from the parent class, unless the attributes are mandatory in some other parent class from which the child inherits, in which case they are also mandatory in the child.
A database object is an instance of an object class. Different objects of the same class have the same mandatory attributes but may have different current values in their corresponding mandatory attributes. Different objects of the same class may have different optional attributes, and/or different current values in their corresponding optional attributes.
The hierarchical database may also be a "synchronized-partition" database. Such a database is typically divided into two or more non-overlapping partitions. To improve the response time to database queries and to provide fault-tolerance, a replica of each partition is physically stored on one or more file servers in the network. The replicas of a given partition are regularly updated by the directory services provider through an automated synchronization process, thereby reducing the differences between replicas caused by activity on the network.
In addition to organizing information by grouping objects into classes and subtrees, hierarchical databases can be used to control access to information and other resources. For instance, commercially available NDS software provides at least three means for controlling access: access control lists, inherited rights filters, and security equivalence. These access control tools are discussed at pages 389-401 of NetWare 4 and elsewhere. For convenience, however, aspects of these access control methods are repeated here.
An access control list is an optional property of every object class. Multiple access control lists may exist on a single object, and there is no limit (other than space and efficiency considerations) on the number of access control lists per object. The access control lists of an object identify trustees who are given rights to access properties of that object.
Each access control property has three parts. The first part identifies a trustee object which receives access rights. The second part identifies a property type, thereby indicating the property or properties for which those access rights are given. Property types include "object rights," "all properties rights," and specific properties.
The third part of the access control property identifies at least one access right that is given to the trustee object for properties of the indicated property type. For "object rights," possible access rights include rights to browse, create, delete, rename, or supervise. For "all properties rights," possible access rights include rights to compare, read, write, add, delete, or supervise.
Rights granted to "object rights" or by "all properties rights" by an access control property are inherited. For instance, rights granted at a container apply downward from the container, to all objects in the subtree of which the container is the root. Rights granted to a specific property are not inherited, but rights limited to a specific property of a group of objects may be granted by placing an appropriate access control property on each object in the group, or by placing an appropriate security equivalence property on each of those objects.
Security equivalence is implemented by using an optional Security Equals property. This property contains the names of other objects in the tree. The object having the Security Equals property then derives access rights from the other objects named in the Security Equals property. More precisely, each object is security equivalent to "public," to "root," to every object in its distinguished name, and to every object in its Security Equals property, in that order.
The inheritance of rights may be filtered. This capability is sometimes call "rights masking." An inherited rights filter determines which rights can be inherited in the object hierarchy from a given point downward. Rights masking is implemented in NDS in the same structure as an access control list, with a filter taking the place of the trustee name. Thus, the inherited rights filter can designate object properties, all properties, or a specific property. The filter does not grant rights. Instead, it places limits on which rights can be granted.
It is often desirable to grant rights suitable for administration of particular resources. For instance, a printer administrator would need rights to add, delete, and modify printer objects in a subtree. A telephone number administrator would need rights to modify telephone numbers on user objects. A password administrator would need rights to change a user's password when the user forgets the original password. And a personnel administrator would need rights to create, modify, delete, and move user objects to reflect personnel changes. Moreover, it is desirable to grant these specialized administration rights in a way that is compatible with existing access control mechanisms, so that the database is not taken out of service during a long and painful conversion process.
One conventional approach is to give each of these specialized administrators supervisor rights to the appropriate subtree(s). Unfortunately, this gives the specialized administrators more rights than are strictly necessary. Granting excess rights may lead at best to inconsistent attempts to change the database, as when one administrator updates a phone number and another later inadvertently loses the update by restoring data from an old backup. At worst, granting excess rights may lead to a security breach which compromises the secrecy and/or integrity of information in the database.
Another approach is to place an appropriate access control property on each administered object. However, rather than easing administration, this creates significant maintenance burdens. The number of objects involved is often large, and updating the access control properties in a large subtree can be time-consuming, tedious, and error-prone.
Thus, it would be an advancement in the art to provide a system and method for efficiently granting limited rights to specialized administrators in a hierarchical database.
It would be an additional advancement to provide such a system and method which are extensions of the capabilities of existing access control mechanisms, and hence can be used in conjunction with existing mechanisms.
Such a method and system are disclosed and claimed herein.